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ISO Statement on the Status of this Document. 


At its meeting in Zurich, April 2-11, 1984, SC 6/WG 2 produced document 
SC 6 N 3134 and, in accordance with Resolution 49 of the SC 6 meeting in 
Tianjin (September 19-30, 1983), forwarded it to the SC 6 Secretariat 
for registration and ballot as a first Draft Proposed Addendum to the 
Network Service Definition (ISO DP 8348/DAD2). 


The letter ballot on SC 6/N 3134 closed on August 20, 1984. The results 
of the ballot were 10-4-0-3 [approve-disapprove-abstain-no vote]; the 
summary of voting is contained in document SC 6/N 3229 (late votes are 
contained in documents SC 6/N 3333 and 3360). These ballot results were 
reviewed at the SC 6/WG 2 meeting in Washington, October 15-25, 1984, 
and document SC 6/N 3444 was produced as a progression of SC 6/N 3134, 
taking into account as many of the ballot comments as possible. The 
Editor’s report, contained in document SC 6/N 3445, describes the 
disposition of member body comments on the DP 8348/DAD2 letter ballot. 


A resolution of the SC 6 meeting in Washington, October 22-26, 1984, 

instructs the SC 6 Secretariat to register document SC 6/N 3444 as a 

second Draft Proposed Addendum to ISO 8348, and to circulate it fora 
two-month letter ballot. 


Introduction 


This Addendum to the Network Service Definition Standard, ISO 8348, 
defines the abstract syntax and semantics of the Network Address 
(Network Service Access Point Address). The Network Address defined in 
this Addendum is the address that appears in the primitives of the 
connection-mode Network Service as the calling address, called address, 
and responding address parameters, and in the primitives of the 
connectionless-mode Network Service as the source address and 
destination address parameters. 
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SCOPE AND FIELD OF APPLICATION 


The scope of this Addendum is the definition of the abstract syntax and 


semantics of the Network Address. 


This Addendum does not specify the 


way in which the semantics of the NSAP address are encoded in Network 


Layer protocols. 
as the field of 
(ISO 
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Temporary Note 

The list of References in the published Addendum will contain 


only approved ISO Standards and CCITT Recommendations; items may need 
to be subtracted from, or added to, the current list. 
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SECTION ONE - GENERAL 


3 DEFINITIONS 

3.1 Reference Model Definitions 

This Addendum makes use of the following terms defined in ISO 7498: 
a) Network layer 

b) Network service 

c) Network service access point 


d) Network service access point address 


e) Network entity 

f) Routing 

g) Network address 

h) Network protocol control information 

i) Network protocol data unit 

3.2 Service Conventions Definitions 

This Addendum makes use of the following terms defined in ISO 8509: 
j) Service user 

k) Service provider 

3.3 Network Layer Architecture Definitions 


This Addendum makes use of the following terms defined in ISO 8648 
(Internal Organization of the Network Layer): 


1) Subnetwork 

m) Real subnetwork 

n) Subnetwork service 
o) Real end system 

p) Interworking unit 


q) Intermediate system 
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3A 


Network Addressing Definitions 


This Addendum makes use of the following terms as defined below: 


r) 


DTE address: information used to identify a point of attachment to 
a public data network. 


Subnetwork point of attachment: a point at which a real end system, 
interworking unit, or real subnetwork is attached to a real 
subnetwork, and a conceptual point at which a subnetwork service is 
offered within an end or intermediate system. 


Subnetwork address (Subnetwork point of attachment address): 
information used in the context of a particular real subnetwork to 
identify a subnetwork point of attachment, or information used in 
the context of a particular subnetwork to identify the point at 
which the subnetwork service is offered within an end or 
intermediate system. 


Network protocol address information: information encoded in a 
network protocol data unit to carry the semantics of an NSAP 
address. (This is known as an "address signal" or as the "coding of 
an address signal" in the Public Data Network environment.) 


Domain (of the OSI environment): a subset of the OSI environment 
within which identifiers for OSI environment entities of the same 
type are unambiguous. 


Global network addressing domain: the set of all Network Service 
Access Point addresses in the OSI environment. 


Network addressing subdomain; a subset of the global network 
addressing domain. 


Authority (for a domain or subdomain): that which ensures that 
identifiers within the corresponding domain or subdomain are 
unambiguous. 
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April 


ABBREVIATIONS 


This Addendum makes use of the following abbreviations: 


a) 


No 


ISO/TC-97/SC-6 


NSAP - Network Service Access Point 

NPAI - Network Protocol Addressing Information 
DCC - Data Country Code 

CC - Country Code 

ICD - International Code Designator 

PSTN - Public Switched Telephone Network 
ISDN - Integrated Services Digital Network 
IDP - Initial Domain Part 

AFI - Authority and Format Identifier 

IDI - Initial Domain Identifier 

DSP - Domain Specific Part 

NPDU - Network Protocol Data Unit 

SNPA - Subnetwork Point of Attachment 
CONVENTIONS 


particular standard conventions are invoked by this Addendum. 


1985 
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SECTION TWO - NETWORK LAYER ADDRESSING 


6 CONCEPTS AND TERMINOLOGY FOR NETWORK LAYER ADDRESSING 


6.1 Network Addresses 


This Addendum defines the Network Service Access Point (NSAP) 
address. Since the term "network address" is commonly used in different 
contexts to refer to different things a more specific description of 
this concept is introduced below. 


6.1.1 Subnetwork Address 


In one context, the term "network address" may be used to refer to the 
point at which a real end system, real subnetwork, or interworking 
unit is attached to a real subnetwork, or to the point at which the 
subnetwork service is offered within an end or intermediate system. 

In the case of attachment to a public data network, this point is 
called a DTE/DCE interface, and the term "DTE address" is used in 
reference to it. 


The specific term "subnetwork address" (or "subnetwork point of 
attachment address") is used in this case, as illustrated in Figure 
6-1: 


subnetwork point of 
attachment identified 


by SNPA 
| AX 
| | | KARR 
| Real End | Layer | * <-/ |\-> * | Layer 
system, real | 3 3 
subnetwork, or Real | | | | 
| interworking | | Subnetwork | | | | 
| unit a | | Ma a | 
| | | 
subnetwork point of End Intermediate 
attachment identified System System 


by subnetwork address 


Figure 6-1 - Subnetwork Address 
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The subnetwork address is the information that a real subnetwork needs 
to identify a particular real end system, another real subnetwork, or 
interworking unit that is attached to that real subnetwork. 


In the public network environment, the subnetwork address is what the 
public network operates on. 


Note: The point identified by a subnetwork address is a point of 
interconnection between a real end system or interworking unit anda 
real subnetwork (in particular, in a public data network environment, 
a DTE/DCE interface), and is not an OSI Service Access Point. 


6.1.2 NSAP address 


In another context, the term "network address" is used to refer to the 
Network Service Access Point (NSAP) at which the OSI Network Service 
is made available to a Network Service user by the Network Service 
provider. 


The specific term "NSAP address" is used in this case, as illustrated 
in Figure 6-2: 


Network Service User 


layer 4 
0 
\ 
layer 3 \ NSAP identified 
by NSAP address 


Network Service Provider 
Figure 6-2 - NSAP Address 


The NSAP address is the information that the OSI Network Service 
provider needs to identify a particular Network Service Access Point. 
The values of the called address, calling address, and responding 
address parameters in the N-CONNECT primitive, of the responding 
address parameter in the N_DISCONNECT primitive, and of the source 
address and destination address parameters in the N-UNIDATA primitive, 
are NSAP addresses. 


Note that since the Network Service primitives are conceptual, no 
particular encoding of the NSAP address is specified by the Network 
Service Definition. 


In both CCITT and ISO usage, the terms "Network Address" (with both 


the N and the A printed in capital letters) and "global network 
address" are synonymous with the term "NSAP address". Use of the term 


ISO/TC-97/SC-6 [Page 9] 


RFC 941 April 1985 
Network Layer Addressing 


6. 


I 


"NSAP address" is preferred when it is essential to avoid confusion, 
particularly in spoken references where "capitalization" is not 
possible. 


6.1.3 Network Protocol Address Information 


In a third context, the term "network address" is used to refer to an 
address that is carried as network protocol control information in a 
network protocol data unit (NPDU). 


The specific term "network protocol address information" (NPAI) is 
used in this case. 


In the public network environment, NPAI is also known as an "address 
signal" or as the "coding of an address signal". 


There is a relationship between the NSAP address that appears in 
Network Service primitives and the NPAI that appears in a Network 
Layer protocol, in that the semantics of the NSAP address is preserved 
by the NPAI. The syntax and encoding of NPAI are defined by Network 
layer Protocol standards, which also specify the relationship between 
the NSAP address and the NPAI encoding employed by the protocol. 


2 Domains 

A domain is a subset of the Open Systems Interconnection environment 
within which identifiers for OSI environment entities of the same type 
are unambiguous. 


6.2.1 Global Network Addressing Domain 


The global network addressing domain is defined as the set of all 
Network Service Access Point addresses in the OSI environment. 


6.2.2 Network Addressing Subdomain 
A network addressing subdomain is a set of Network Service access 
Point addresses. It is a subset of the global network addressing 


domain. 


The relationship of the concepts of 6.2.1 and 6.2.2 is illustrated by 
Figure 6-3: 
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6.3 Authorities 


The uniqueness of identifiers within a domain or subdomain is ensured 
by an authority associated with that domain. The term "authority" does 
not necessarily refer to an organization or administration: it is 
intended to refer to whatever it is (in an abstract sense) that ensures 
the uniqueness of identifiers in the associated domain. 


Domains are characterized by the authority that administers the domain 
and by the rules that are established by that authority for specifying 
identifiers and identifying subdomains. The authority responsible for 
each subdomain determines how identifiers will be assigned and 
interpreted within that subdomain, and how any further subdomains will 
be created. 


The operation of an authority is independent of that of other 
authorities on the same level of the hierarchy, subject only to any 
common rules imposed by the parent authority. 


6.4 Network Address Allocation 


An addressing authority shall either allocate complete NSAP addresses, 
or shall authorize one or more other authorities to allocate address. 
Each address allocated by an addressing authority shall include a 
domain identifier which identifies the allocating authority. An address 
shall not be allocated to identify a domain or NSAP if the address has 
previously been allocated to some other domain or NSAP, unless the 
authority can ensure that all use of the previous allocation has 
ceased. 


The authority shall ensure that allocations are made in such a way that 
efficient use is made of the address space. 


7 PRINCIPLES FOR CREATING THE OSI NETWORK ADDRESSING SCHEME 


7.1 Hierarchical Structure of NSAP Addresses 


NSAP addresses are based on the concept of hierarchical addressing 
domains, as explained in Clause 6. Each domain may be further 
partitioned into subdomains. Accordingly, NSAP addresses have a 
hierarchical structure. 


The conceptual structure of NSAP addresses follows the principle that, 
at any level of the hierarchy, an initial part of the address 
unambiguously identifies a subdomain, and the rest is allocated by the 
management of the subdomain to unambiguously identify either a lower 
level subdomain or an NSAP within the subdomain. The part of the 
address that identifies the subdomain depends on the level at which the 
address is viewed. 
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Note: This conceptual structure should not be considered as implying 
any detailed administration of NSAP addresses. 


Graphical representation of the hierarchical structure of NSAP 
addresses may be made according to an inverted tree diagram, as in 
Figure 7-1 (a), or a domain diagram, as in Figure 7-1 (b) 


O 
| 
| 
| | | | 
| | | | 
| w | | x | | x | |i ea 
| | | 
| | | 
| | | | | 
lal |b] Je] [al Ib] 
| 
| 
| | | | 
| | | | 
lel lal Iri Is] 
Figure 7-1 (a) - Hierarchical Structure of NSAP Addresses 


Inverted Tree Diagram 
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Figure 7-1 (b) - Hierarchical Structure of NSAP Addresses 
Domain Diagram 
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7.2 Global Identification of any NSAP 
In the context of Open Systems Interconnection, it is possible to 
identify any NSAP within the global network addressing domain (see 


Clause 6.2.1). Consequently, 


a) At any Network Service Access Point, it is possible to identify 
any other Network Service Access Point, within any OSI end system; 


b) A global Network Address can therefore be defined to unambiguously 
identify any Network Service Access Point; 


c) The OSI protocols established between correspondent Network 
entities convey the complete information contained in a Network 
Address (see Clause 6.1.4); 


d) An NSAP address identifies the same NSAP regardless of which 
NS-user enunciated the address; and 


e) An NS-user, when given an NSAP address of the NS-provider ina 
primitive Indication, may subsequently use that NSAP address in 
another instance of communication with the corresponding NSAP. 


Some restrictions may be placed on communications in the context of 
OSI, on the basis of: technical feasibility of an interconnection, 
security, charging, etc. Such considerations are not related to Network 
Layer addressing, and therefore are not discussed in this Addendum. 


Note: The global identification of NSAPs should not be taken to imply 
the universal availability of directory functions required to enable 
communication among all NSAPs to which NSAP addresses have been 
allocated. 


7.3 Route Independence 


Network Service users cannot derive routing information from an NSAP 
address. They cannot influence the Network Service provider’s choice of 
route by means of the source and destination NSAP addresses. Similarly, 
they cannot deduce from the source and destination NSAP addresses the 
route that was used by the Network Service provider. This is not 
intended to exclude the possibility that an OSI end system may need to 
influence the route selected for a particular instance of communication 
with another OSI end system. (In particular, it may need to influence 
the selection of intermediate systems to be used, and the paths to be 
taken between them.) The means whereby such an influence may be exerted 
is, however, not the NSAP address. Elements of Network Layer protocol 
may be required to control routing within intermediate systems; such 
elements of protocol are distinct from the network protocol address 
information (NPAI). 


Notwithstanding the restrictions imposed on the use that a Network 
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Service user may make of an NSAP address, it is recognized that NSAP 
addresses should be constructed in such a way that routing through 
interconnected subnetworks is facilitated. That is, the Network Service 
provider and relay-entities in particular, may take advantage of the 
address structure to achieve economical processing of routing aspects. 


7.4 Service Type Independence 


It may be necessary for Network Service users to distinguish Network 
Layer services of different types (such as point-to-point versus 
multipoint services, and connection-mode versus connectionless-—mode 
services). The nature of such service types is not explicitly contained 
in the semantics of the NSAP address. Similarly, Network Layer quality 
of service characteristics (such as throughput, transit delay, etc.) 
are not explicitly specified by the NSAP address. 


8 NETWORK ADDRESS DEFINITION 


The intent of this document is best served by maintaining clear 
distinctions among three concepts: the abstract semantics of the NSAP 
address; the abstract syntax employed in this document as a means of 
defining the abstract semantics of the NSAP address, and employed by 
addressing authorities as a means of allocating and assigning addresses; 
and the concrete syntax in which the NSAP address semantics are encoded 
as NPAI in Network Layer protocols. These distinctions are illustrated 
in Figure 8-1: 


NSAP Address Semantics------- >Allocation by------- >Abstract Syntax 


—->Representation in--->External 


Humanly-readable Reference 
Directories Syntax 

|-->Encoding in--------- >Concrete Syntax 
Protocols 


Figure 8-1 - Relationship of NSAP Address Semantics and Syntax 


This Addendum does not specify the way in which the semantics of the 
NSAP address are encoded in Network Layer protocols. Network Layer 

protocol specifications define the way in which the NSAP address is 

encoded as NPAI (see clause 6.1.4). 
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8.1 Network Address Semantics 


The NSAP address consists of two basic semantic parts. The first part 
is the Initial Domain Part (IDP). The second part is the Domain 
Specific Part (DSP). This is illustrated by Figure 8-2. 


Following the conceptual structure of NSAP addresses described in 
Clause 7.1, the IDP is a subdomain identifier: it specifies the 
subdomain of the global network addressing domain (see Figure 7-1), and 
identifies the authorities responsible for assigning addresses in each 
of the subdomains created. The DSP is the corresponding subdomain 
address. A further substructure of the DSP may or may not be defined by 
the authority identified by the IDP. 


8.1.1 The IDP 


The Initial Domain Part of the NSAP address itself consists of two 
parts. The first part is the Authority and Format Identifier (AFI). 
The second part is the Initial Domain Identifier (IDI). This is 
illustrated by Figure 8-2: 


<---------------------- NSAP ADDRESS------------------------- > 
| | | 
| IDP | DSP | 
| AFI | IDI | 


Figure 8-2 - NSAP Address Structure 
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8.1.1.1 The AFI 
The Authority and Format Identifier specifies: 
a) the format of the IDI (see clause 8.2.1.2); 


b) the authority responsible for allocating values of the IDI (see 
clause 8.2.1.2) and 


c) the abstract syntax of the DSP (see clauses 8.2 and 8.2.3). 


8.1.1.2 The IDI 
The Initial Domain Identifier specifies: 


a) the Network Addressing subdomain from which values of the DSP 
are allocated; and 


b) the authority responsible for allocating values of the DSP from 
that subdomain. 


8.1.2 The DSP 


The semantics of the DSP is determined by the authority identified by 
the IDI (see clause 8.1.1.2). 


8.2 Network Address Abstract Syntax 


The Network Address is defined in this Addendum in terms of an abstract 
syntax which expresses the semantics of the Network Address. The use of 
this abstract syntax as a descriptive device enables this Addendum to 
convey, in written form, a complete definition of the Network Address 
without restricting it to the specific encoding of the NPAI. It also 
enables this Addendum to identify two alternative preferred concrete 
synataxes of the Network Address, to which reference may be made by 
Network Layer protocol specification standards so as to unambiguously 
define the way in which the Network Address is encoded as NPAI. 


8.2.1 Abstract Syntax and Allocation of the IDP 


This clause defines the abstract syntax of the AFI, the currently 
allocated values of the AFI, and the IDI formats corresponding to the 
allocated AFI values. Among the currently allocated values of the 
AFIsare values reserved for assignment to new IDI formats which may be 
identified by ISO or CCITT. Assignment of these AFI values to new IDI 
formats by either ISO or CCITT must be accompanied by appropriate 
modification of this Addendum according to the rules established by 
ISO for revising International Standards. Allocation of new AFI values 
will be by joint agreement between ISO and CCITT, and will require an 
appropriate modification of this Addendum. 
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The abstract syntax of the IDP is decimal digits. The allocation of 
the AFI (see Clause 8.1.1) ensures that the first decimal digit of the 
IDP can never be zero. This provides a escape mechanism for use by 
protocols that expect to hold incomplete NSAP addresses in a field 
that normally carries a complete NSAP address. When the NSAP address 
is represented as binary octets, the representation of the IDP is as 
defined in Clause 8.3.1. 


The length of the IDP depends on the IDI format specified by the value 
of the AFI. The IDP length associated with each IDI format is given in 
clause 8.2.1.2. 

8.2.1.1 Abstract Syntax and Allocation of the AFI 

The AFI consists of an integer with a value between 0 and 99 with an 


abstract syntax of two decimal digits. The values of the AFI are 
allocated or reserved as shown in Table 8-1: 


Table 8-1: AFI ALLOCATIONS 
00-09 Reserved - will not be allocated 


10-35 Reserved for future allocation by joint agreement 
of ISO and CCITT 


36-51 Allocated and assigned to the IDI formats defined 
in clause 8.2.1.2 


52-59 Reserved for future allocation by joint agreement 
of ISO and CCITT 


60-69 Allocated for assignment to new IDI formats by 
ISO 

70-79 Allocated for assignment to new IDI formats by 
CCLLT 

80-99 Reserved for future allocation by joint agreement 


of ISO and CCITT 
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8.2.1.2 Format and Allocation of the IDI 


A specific combination of IDI format and DSP abstract syntax is 
associated with each allocated AFI value, as summarized in Table 8-2: 


Table 8-2: AFI Values 


| DSP Syntax | 
| | 
| | | 
| Decimal | Binary | 
|IDI format | | | 
| | 
| x121 36 37 
| | 
| Iso DCC 38 39 | 
| | 
| F.69 40 41 | 
| E.163 42 43 | 
| | 
| E.164 44 45 | 
| |Character | National | 
|ISO 6523-ICD 46 47 | (īso 646) |Character | 
| 
| Local 48 49 50 51 
| 


The IDI formats are defined as follows: 
a) X.121 
The IDI consists of a sequence of up to 14 digits allocated 
according to CCITT Recommendation X.121. The X.121 number 
identifies an authority responsible for allocating and assigning 
values of the DSP. 
IDP length: Up to 16 digits. 
b) ISO DCC 
The IDI consists of a three-digit Data Country Code (DCC). ISO DCC 
values are allocated by ISO and assigned to ISO member countries or 


appropriately sponsored non-member countries or authorities. The 
values of the ISO DCC are a subset of the DCC values allocated by 
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CCITT in Recommendation X.121 to countries or geographical areas. 
The DSP is allocated and assigned by the organization that 
represents the country identified by the DCC. 
IDP length: 5 digits. 
c) F.69 


The IDI consists of a telex number of up to 8 digits, allocated 
according to CCITT Recommendation F.69, commencing with a 2- or 
3-digit destination code. The telex number identifies an authority 
responsible for allocating and assigning values of the DSP. 


IDP length: Up to 10 digits. 
d) E.163 
The IDI consists of a public switched telephone network (PSTN) 
number of up to 12 digits allocated according to CCITT 
Recommendation E.163, commencing with the PSTN country code. The 
PSTN number identifies an authority responsible for allocating and 
assigning values of the DSP. 
IDP length: Up to 14 digits. 
e) E.164 
The IDI consists of an ISDN number of up to 15 digits allocated 
according to CCITT Recommendation E.164, commencing with the ISDN 
country code. The ISDN number identifies an authority responsible 
for allocating and assigning values of the DSP. 
IDP length: Up to 17 digits 
f) ISO 6523-ICD 
The IDI consists of a 4-digit International Code Designator (ICD) 
allocated according to ISO 6523. The ICD identifies an 
organizational authority responsible for allocating and assigning 
values of the DSP. The "structure of the code" required by ISO 6523, 
clause 6.3(d), shall be registered as "According to ISO 8348 
Addendum 2". 
IDP length: 6 digits. 
g) LOCAL 
The IDI is null. 


IDP length: 2 digits. 
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Note 1: 
In cases (a), (c), (d), and (e) above, when the IDP is followed by a 
decimal-syntax DSP, no discernible boundary is identified in this 
Addendum between the IDP digits and the DSP digits. 


Note 2: 


A figure illustrating the division of the global network addressing 
domain according to these formats is contained in Annex B. 


Note 3: 


The use of a particular IDI format as the basis for allocating an 
NSAP address does not constrain routing to that NSAP to go through 
any particular subnetwork. For example, the use of the E.163 IDI 
format as the basis for allocating an NSAP address does not mean 
that access to the NSAP necessarily involves use of the telephony 
subnetwork (see clause 7.3). 


Note 4: 


Formats a, c, d, and e are based on specific CCITT numbering plans, 
and as such may be affected by any changes to those plans. It 
should be understood that in identifying and describing these 
formats, this Addendum observes the current status of CCITT work on 
numbering plans, and does not establish any preference or position 
whatsoever concerning the way in which CCITT may choose to modify 
the plans, or their relationships with one another, in the future. 
Changes to this may be necessary to take any such further work by 
CCITT into account. For example, the CCITT numbering plans in some 
cases may provide escape mechanisms (such as a zero, 8, or 9 prefix) 
from one numbering plan to another. This results in the possibility 
of a choice that must be made concerning which of formats a, c, d, 
and e should be used for the allocation of NSAP addresses, and may 
also lead to suggestions that it is not necessary to include all of 
the formats a, c, d, and e in this Addendum. Such choices, however, 
are made within the context and responsibility of CCITT, and no 
preference for one choice or another is made or implied by this 
Addendum. 


8.2.2 Abstract Syntax and Allocation of the DSP 


Values of the DSP are allocated by the authority identified by the IDI 
in the syntax identified by the AFI (see clauses 8.1.1.2 and 8.2.1.2). 


The allocating authority specifies the format and semantics of the 
DSP. If the authority identified by the IDI authorizes one or more 
authorities to allocate semantic parts of the DSP, then all those 
authorities must allocate using the same abstract syntax used by the 
parent authority. 
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An authority may choose to allocate NSAP addresses with the DSP ina 
decimal or binary abstract syntax for all IDI formats, and may choose 
to allocate NSAP addresses with the DSP in a character (ISO 646) or 
National Character abstract syntax when the IDI format is "Local" (see 
Table 8-2). Clause 9 describes the latter case in detail. 


8.2.3 Abstract Syntax of the DSP 


The DSP may be allocated by the responsible authority in one of four 
syntaxes, depending on the value of the AFI: 


a) Binary: The DSP consists of zero or more binary octets, up to 
the maximum specified in Table 8-3. 


b) Decimal: The DSP consists of zero or more decimal digits, up 
to the maximum specified in Table 8-3. 


c) Character: The DSP consists of zero or more of those graphic, 
characters with no national variant, plus the space 
character, from ISO 646, up to the maximum specified 
in Table 8-3. 


d) National Character: The DSP consists of zero or more characters 
from a character set determined by the allocating 
authority, up to the maximum specified in Table 8-3. 
Table 8-3 gives the maximum length of the DSP in its abstract syntax 
for each of the IDI formats defined in clause 8.2.1.2. The 
corresponding total NSAP address lengths are given in clause 8.4. 


8.3 Network Address Concrete Syntax 


As describe in Clause 8.1, the semantics of the NSAP address consists 
of three fields in the following order: 


a) the AFI, with an abstract syntax of two decimal digits; 


b) the IDI, with an abstract syntax of a variable number of decimal 
digits; and 
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Table 8-3: Maximum DSP Length 


| DSP Syntax | 

| | 

| | | 

Decimal Binary 

|IDI format | | 
| | | | 
| Seal 24 9 | 
| | 
| ISO DCC 35 14 | 
| | 
| F.69 30 12 | 
| E.163 26 10 | 
| | 
| E.164 23 9 | 
| |Character | National | 
e 6523-ICD 34 13 hee 646) |Character 
| Local 38 15 19 7 
| 


c) the DSP, with an abstract syntax of a variable number of one and 
only one of the following types: binary octets, decimal digits, 
characters, or national characters. 


This Addendum does not specify the way in which the semantics of an 
NSAP address are encoded in Network Layer protocols by a concrete 
syntax in NPAI (see Note following this clause). These encodings are 
specified in Network Layer protocol standards. 


Note: Encoding implies more than a concrete syntax, such as the order 
of bit transmission, representation as tones or other signals, etc. 


Nevertheless, this Addendum identifies two alternative concrete 
syntaxes (see clauses 8.3.1 and 8.3.2) of the Network Address. 
Reference to these may be made by Network Layer protocol specification 
standards. It is possible that the concrete syntax used to encode the 
Network Address as NPAI in a Network Layer protocol may be chosen to be 
identical to one of these concrete syntaxes. It is not required that 
this be the case, however (see clause 9). 


The entire NSAP address taken as a whole may be represented explicitly 
as a string of either decimal digits (decimal concrete syntax) or 
binary octets (binary concrete syntax) as defined below. Network Layer 
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protocol specifications making reference to this Addendum shall specify 
the way in which either the decimal concrete syntax or the binary 
concrete syntax of the NSAP address (or both) is encoded as NPAI (see 


clause 6.1.3). 
8.3.1 Binary Concrete Syntax 


The binary concrete syntax is generated by: 


a) using two semi-octets to represent the two digits of the AFI, 
yielding a value for each semi-octet in the rage 0000-1001; 


b) padding the IDI with leading zero digits if necessary to obtain 
the maximum IDI length (specified for each IDI format in clause 


8.2.1.2), then using a semi-octet to represent the value of each 
decimal digit (including leading padding digits, if preset), 

yielding a value in the range 0000-1001; and, if the DSP syntax 
is not decimal digits, using the semi-octet value 1111 as a pad 


after the final semi-octet (if necessary) to obtain 
number of octets; 


an integral 


c) representing a decimal syntax DSP using the technique described in 


(b); 
d) representing a binary syntax DSP directly as binary 
e) when the IDI format is "Local", representing an ISO 


syntax DSP by converting each character to a number 
32-127 using the ISO 646 encoding, with zero parity 


octets; 


646 character 
in the range 
and the 


parity bit in the most significant position, reducing the value 
by 32, giving a number in the range 0-95, encoding this result as 
a pair of decimal digits; and applying the technique described in 


(b); and 


f) when the IDI format is "Local", representing a National Character 


syntax DSP by converting each national character to 


either one or 


two octets according to the rules specified by the authority 


responsible for allocating NSAP addresses including 
character DSP syntaxes. 


8.3.2 Decimal Concrete Syntax 


The decimal concrete syntax is generated by: 


national 


a) representing the two digits of the AFI directly as two decimal 


digits; 


b) padding the IDI with leading zero digits if necessary to obtain 
the maximum IDI length (specified for each IDI format in Clause 
8.2.1.2), representing the result directly as decimal digits; 
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c) representing a decimal syntax DSP directly as decimal digits; 
d) representing a binary syntax DSP as follows: 
Taking the octets in pairs, convert each octet of the pair toa 
number in the range 0-255; this generates six decimal digits, 
abcdef, of which digits a and d may take on only the values o, 1, or 


2. The pair of octets is represented by the sequence of five digits 
gbcef, where the value of digit g is given in Table 8-4: 


Table 8-4: Values of g. 


\ a 
d \ 0 1 2 
| ol | | | 
| 0 0 1 2| 
| | 
| 1 3 4 5 | 
| 2 6 7 8 | 
| | 


If the original binary field contained an odd number of octets, the 
final octet is converted to a number in the range 0-255 and 
represented as three decimal digits (000-255); 


e) when the IDI format is "Local", representing an ISO 646 
character syntax DSP using the technique described in Clause 
8.3.1 (e); and 


f) when the IDI format is "Local", representing a National 
Character syntax DSP using the technique described in Clause 
8.3.1 (f). 
8.4 Maximum Network Address Length 
The maximum length of the NSAP address for each of the combinations of 


IDI abstract syntax is given in Table 8-5 both the decimal concrete 
syntax and the binary concrete syntax. 
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Table 8-5: Maximum NSAP Address Lengths 


| | DSP Abstract | Binary DSP | Decimal DSP | 
| IDI Format | syntax | concrete syntax concrete syntax | 
| | | | | 
Decimal 20 octets 40 digits 
X L21 Binary 17 octets 39 digits 
| | | | | 
| | Decimal | 20 octets | 40 digits 
| ISO DCC | Binary | 17 octets | 40 digits 
| | | | | 
| | Decimal | 20 octets | 40 digits 
| F.69 | Binary | 17 octets | 40 digits 
| | Decimal | 20 octets | 40 digits 
| E.163 | Binary | 17 octets | 39 digits 
| | | | | 
| | Decimal | 20 octets | 40 digits 
| E.164 | Binary | 18 octets | 40 digits 
| | Decimal | 20 octets | 40 digits 
| ISO 6523-ICD| Binary | 16 octets | 39 digits 
| | | | | 
| | Decimal | 20 octets | 40 digits 
LOCAL Binary 16 octets 40 digits 
Character 20 octets 40 digits 
| [National Char. | 15 octets | 37 digits 
| | | | | 
Note: These values assume a National Character representation of one 


character as two binary octets (see clause 8.2.3). 
From this table it is clear that: 


a) the maximum length of an NSAP address in its binary concrete syntax 
is 20 octets; and 


b) the maximum length of an NSAP address in its decimal concrete 
syntax is 40 digits. 


A Network Layer protocol which is capable of conveying a string of 
variable length with a maximum length of either 20 binary octets or 40 
decimal digits is capable of encoding the full semantic content of any 
Network Address. 
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9 CHARACTER BASED DSP ALLOCATION 


An authority may choose to allocate NSAP addresses with the DSP ina 
National Character syntax. In such cases, the allocating authority must 
define and publish the mapping of the National Character syntax to 
either a binary abstract syntax or a decimal abstract syntax. 


Note: It is recommended that this mapping be done by reference to the 
ISO Register of Character Sets, which is maintained by the European 
Computer Manufacturers Association (ECMA) acting as a registration 
authority according to ISO 2375, "Procedure for the Registration of 
Escape Sequences". 


In the case where the authority defines and publishes the mapping of the 
National Character set to a binary abstract syntax, the result must be 
representable in either one or two octets per National Character. In 
this case, the resulting DSP is considered to be based on the Binary 
abstract syntax. AFI values from Table 8-2 and the mapping to binary and 
decimal concrete syntaxes are based on the binary abstract syntax. 


In the case where the authority defines and publishes the mapping of the 
National Character set to a decimal abstract syntax, the result must be 
representable in up to five decimal digits per National Character. In 
this case, the resulting DSP is considered to be based on the decimal 
abstract syntax. AFI values from Table 8-2 and the mapping to binary and 
decimal concrete syntaxes are based on the decimal abstract syntax. 


Note: The ability to base DSP allocation on National Character sets 
allows DSP allocation based on international character sets. This may 
simplify address assignment in some cases, and may facilitate 
representation of NSAP address in humanly-readable form. Nevertheless, 
NSAP addresses should not be confused with Application Layer entity 
titles. NSAP addresses are not intended to provide the same degree of 
human-readable, user-friendly naming and addressing capabilities as 
may be expected in Application Layer entity titles. 
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10 REFERENCE PUBLICATION FORMATS 


Reference publication formats are defined to allow unambiguous 
representation of NSAP addresses in both written and oral communication. 


10.1 Decimal Reference Publication Format 


The Decimal reference publication form (DRPF) consists of a string of 
up to 40 decimal digits. The DRPF is the written inscription of the 
decimal concrete syntax defined in clause 8.3.2. 


10.2 Hexadecimal Reference Publication Format 


The Hexadecimal reference publication format (HRPF) consists of the 
symbol "/" (solidus) followed by a string of up to 40 hexadecimal 
digits. The HRPF is the written inscription of the binary concrete 
syntax defined in clause 8.3.1, using two hexadecimal digits ranging 
from 00 through FF to represent each binary octet. 
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ANNEX A - NETWORK ENTITY TITLES 
This Annex is an integral part of the Addendum. 


In order to perform routing functions and to distribute Network Layer 
management information concerning routing among Network entities, it is 
necessary to be able to unambiguously identify Network entities in end 
systems and intermediate systems. The Reference Model (ISO 7498) 
provides a definition of the concept of an (N)-entity title, which may 
be used to permanently and unambiguously identify a Network entity in an 
end system or intermediate system. 


Any authority responsible for allocating addresses to NSAPs may choose 
also to allocate Network entity titles. One of the ways in which this 
can be done is to use the principles and mechanisms defined in this 
Addendum for allocating Network addresses. When this approach is taken, 
a Network entity title has the same abstract syntax as an NSAP address. 
A value may be allocated as a Network entity tile only if it has not 
been allocated as an NSAP address. 
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ANNEX B - NSAP ADDRESS ALLOCATION 

This Annex is not an integral part of the Addendum. 

The division of the global Network addressing domain according to the 
IDI formats described in clause 8.2.1.2 may be illustrated by the 
following figure. The numbers adjacent to each line in the figure are 


AFI values, as defined in Table 8-2 of clause 8.2.1.2. 


Figure B-1 - NSAP Address Allocation on attached page. 


00-09 Reserved - will not be allocated 

10-35 Reserved for future allocation by joint agreement of ISO 
and CCITT 

36-37 X.121 

38-39 ISO DCC 

40-41 F.69 

42-43 E.163 

44-45 E.164 

46-47 ISO ICD 

48-51 Local 

52-59 Reserved for future allocation by joint agreement of ISO 
and CCITT 

60-69 Allocated for assignment by ISO 

70-79 Allocated for assignment by CCITT 

80-99 Reserved for future allocation by joint agreement of ISO 
and CCITT 
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ANNEX C - RATIONALES 


This annex contains tutorial and explanatory material, and is not an 
integral part of the Addendum. 


C.1 IDI FORMATS (Clause 8.2.1.2) 


The rationale for the use of the specific IDI formats identified in 
Clause 8.2.1.2 is to allow the allocation and assignment of NSAP 
addresses to be based on existing, well-established network numbering 
plans and organization-identification standards. 


The CCITT numbering plans are included so as to allow for the 
designation of the organization to which a number is assigned as an 
authority for the assignment of NSAP addresses. If the organization 
identified by a particular number from one of these plans chooses not 
to define any further sub-addressing beyond that number, then the 
number itself constitutes an NSAP address when it is used in the OSI 
environment. This flexibility allows number allocated from the four 
CCITT numbering plans identified in Clause 8.2.1.2 to be used directly 
as NSAP addresses, with the addition of nothing more than the initial 
AFI digits that identify the plan. 


The ISO DCC format is included so as to allow for the designation, 
where permitted by national regulations, of the organization that 
represents a country in ISO (or an appropriately sponsored 
organization) as an authority for the assignment of 
geographically-based NSAP addresses. The way in which addresses are 
allocated and assigned in the ISO DCC format is determined by the 
designated organization, which might, for example, be the national 
standards body that represents a country in ISO. 


The ISO 6523-ICD format is included so as to allow for the designation, 
where permitted by national regulations, of an organization that may or 
may not be tied to a particular country as an authority for the 
assignment of NSAP addresses according to the hierarchy appropriate for 
that organization (which may not be based on geographical or national 
boundaries). The way which addresses are allocated and assigned in the 
ISO 6523-ICD format is determined by the designated organization, which 
might, for example, be the United Nations World Health Organization. 


The Local format is included so as to allow for proprietary or other 
non-standard network addressing schemes to coexist with the standard 
OSI network addressing scheme. Use of the Local format for these 
non-standard address ensures that they cannot be confused with standard 
OSI network addresses. This capability will be useful in the evolution 
of existing networks to OSI, and for the accommodation of non-OSI 
addressing schemes that may be used in proprietary network 
architectures or for testing and other interim purposes. It should be 
emphasized that 
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the Local format is not intended to give non-OSI schemes a permanent 
place in OSI, but rather to permit the OSI network addressing sheme to 
be used wherever possible without risk of conflict with other schemes 
(which can be encapsulated safely under the Local format). 


C.2 RESERVATION OF AFI VALUES 00-09 (Table 8-2) 


The reservation of AFI values beginning with the digit 0 is intended to 
allow for the use of an initial 0 to handle special cases, such as: 


a) as an escape to some other addressing scheme; 


b) as a technique for the optimization of NSAP address encoding in 
Network Layer protocols, when the different parts of the NSAP 
address semantics are encoded in different fields of the protocol 
header; 


c) as a way to indicate, in a protocol header, that a field that 
ordinarily contains a full NSAP address in fact contains something 
less than a full address (for example, a shorthand form that omits 
specification of the higher-order domains, which might be used for 
communication within a particular subdomain environment). 


There may be other cases in which the use of an initial 0 digit is 
found to be useful. This Addendum merely reserves the AFI values 00-09, 
and does not specify how they might be used; all such uses are outside 
the scope of this Addendum. 


C.3 DERIVATION OF THE CONCRETE SYNTAXES (Clause 8.3) 


In describing the two "preferred" concrete syntaxes of the NSAP 
address, Clauses 8.3.1 and 8.3.2 introduce two types of padding: 
padding with zero digits at the beginning of an IDI, and padding with a 
semi-octet with the value 1111 at the end of the binary encoding of an 
IDI with an odd number of decimal digits. 


The first type of padding is necessary because some of the IDI formats 
allow the IDI to consist of a variable number of digits. Since there is 
no explicit syntactic marker between the IDI and the DSP, the only way 
to find the end of the IDI is to know how long it is. The AFI, which 
identifies which IDI format is used, allows only the maximum length of 
that IDI to be determined. Rather than introduce either a specific 
syntactic marker or a new field containing the length of the IDI 
(either of which would have greatly complicated the encoding and 
parsing of NSAP addresses), the Addendum specifies that for encoding 
purposes the IDI must first be padded out to its maximum length. Note 
that this does not apply to the DSP; only to the IDI. 
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The second type of padding is necessary to ensure that a binary 
encoding of the IDI consists of an integral number of binary octets. 
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